make build tests not depend on minutiƦ of rustc output
authorZack M. Davis <code@zackmdavis.net>
Wed, 1 Feb 2017 04:51:24 +0000 (20:51 -0800)
committerAlex Crichton <alex@alexcrichton.com>
Fri, 3 Mar 2017 19:21:09 +0000 (11:21 -0800)
commitf1c0d44ff0150591e7cedf37ef3d550c3872d408
treea2fd03b9c59d0cbacc2bbe247d345a7666f0c1ea
parentd8fe364e535c48cd3327156d70fa7ada2f781163
make build tests not depend on minutiƦ of rustc output

This little patch arises from the maelstrom of my purity born of pain.

It's the pain of seeing rust-lang/rust#38103 in its perfect
crystalline beauty waste away on page four of
https://github.com/rust-lang/rust/pulls, waiting, ready, itching to
land, dying with anticipation to bring the light of clearer lint group
error messages to Rust users of all creeds and nations, only for its
promise to be cruelly blocked by the fateful, hateful hand of circular
dependency. For it is written in src/tools/cargotest/main.rs that the
Cargo tests must pass before the PR can receive Appveyor's blessing,
but the Cargo tests could not pass (because they depend on fine
details of the output that the PR is meant to change), and the Cargo
tests could not be changed (because updating the test expectation to
match the proposed new compiler output, would fail with the current
compiler).

The Gordian knot is cut in the bowels of cargotest's very notion of
comparison (of JSON objects) itself, by means of introducing a magic
string literal `"{...}"`, which can server as a wildcard for any JSON
sub-object.

And so it will be for the children, and the children's children, and
unto the 1.17.0 and 1.18.0 releases, that Cargo's build test
expectations will faithfully expect the exact JSON output by Cargo
itself, but the string literal `"{...}"` shall be a token upon the
JSON output by rustc, and when I see `"{...}"`, I will pass over you,
and the failure shall not be upon you.

And this day shall be unto you for a memorial.
tests/build.rs
tests/cargotest/support/mod.rs